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Sender: "Pamel a<-A.♦-Dick. osbunorth"©Xerox .COM 
Date: 4 Jun 86 14:08:43 PDT (Wednesday) 
Subject: Re: TypeFounder Beta-test report #1 
From: XDESupport.osbunorthOXerox.COM 


The Typefounder folks had the following comments on 2 of your questions: 

1. Re: The speed of dictionary font access decreases the ’deeper' 
in the dictionary the font is located: 

Quite true. Unlike printer font dictionaries, structure of Viewpoint 
font dictionaries is such that to get to the nth font in the dictionary 
you have to start at the beginning of the file and work your way up. 

It would be possible take an initial pass through the file and build 
an index - this will be considered for future releases. 

2. Re: Symptoms: If you start up the ToolDriver and TypeFounder 

in the correct order, use TypeFounder, then start a ToolDriver script, 
it fails. I found that you have to unload TypeFounder and start it 
fresh before using the ToolDriver. This appears to be due to 
TypeFounder's tool instances being numbered (i.e. Dictionary6) as they 
are created. This is more of an annoyance than a problem. 

This is a bug related to improper handling of pop-up form subwindows 
(for example the 'Viewpoint Format Items' subwindow in the Dictionary 
tool). It will be fixed in the next release. 

The next release of Typefounder will probably be included in the 5.0 
release later this year. 


Sender: "Pamela<-A.*-Dick.osbu north "©Xerox .COM 
Date: 6 Jun 86 10:16:55 PDT (Friday) 

Subject: Re: Typefounder Beta-test Report #2 
From: XDESupport.osbunorth@Xerox.COM 

From the Typefounder Beta-test report #1: 

1. We still don't have an answer to your question on the hor. and 
ver. resolution field. I will ask the Typefounder folks about this 
one again. 

2. In regard to the problem of having to unload Typefounder before 
running a ToolDriver script it should be noted that this problem only 
(as far as we can tell) occurs with the Dictionary. You should be 
able to run scripts which do not use the Dictionary without having 

to unload Typefounder first. 

3. Corrections have been made to the Tool.sws. ChangeWidths is 
actually a pop up window so its entry needs to remain. You can make 
the changes to the Tool.sws file directly, or we can send you another 
copy. The only changes were: 

1. add the [Distributorl], [Distributor], and [Distributor3] fields 
with msgSW, cmdSW as parameters. 

2. remove the [PROMWriterl], [PROMWriter2], and [PROMWriter3] field 
entries. 

4. The typos in the manual will be corrected for the next release. 


From Typefounder Beta-test report #2: 

1. I have submitted bug reports on using the contour editor of the 
Character subtool and fixing the typos in the Reference Manual. We’ll 
get back to you when there is a change in status on bug reports. 

2. I sent in your feature requests. The Typefounder folks thought 
that the UNDO key and the background grid ideas were both good and 
will add them to the proposed additions list. 

Also, in response to the background grid idea: 

This might be a good time to emphasize that Typefounder is not a very 
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good tool for drawing contour characters by hand. We feel it is more 
efficient to produce contours by scan-converting a high resolution 
raster master made from scanned-in artwork, or drawn with software 
(such Viewpoint Freehand Drawing) customized for doing illustrations. 
The knot editor in Typefounder is really designed for small touchups. 

3. I haven't heard anything back yet on the request for displaying 
knots on a background image. I sent in this request later than the 
others, so they might not have had time to look at it yet. 

Any progress on sending us the Camera Tool image which wasn't printing 
correctly? Thanks. 

— Pam 

By the by, XDESupport is moving to Sunnyvale on Monday. Our new phone 
number is (408) 737-4500, and our new address is: 

525 Oakmead Parkway 
Sunnyvale, CA 94086 


Sender: "Pamela<-A.«-Dick.osbunorth"@Xerox .COM 
Date: 18 Jun 86 15:01:54 PDT (Wednesday) 
Subject: Re: TypeFounder Beta-test report #1 
From: XDESupport.osbunorth@Xerox.COM 


1. Re: Hor. Resolution' and 'Ver. Resolution' fields of a Print 
Service... 

In ref. to your question about the Resolution fields of a Font, on 
page 31 of the 3.4 Reference Manual, in the fourth paragraph under 
Notes, use of the Vertical Resolution field for Character Set number 
is explained. The Hor. Resolution field of Print Service fonts contains 
a code describing the strikeout and underline positions for the font. 

We don't use it for that here. We use Hor. Resolution for the actual 
resolution in the fonts we make here and have never had problems 
installing them on the printer. I am going to try to find out the 
actual meaning of the Hor. Resolution field for Print Service fonts 
and will message you about it. 

2. Re: If you start up the ToolDriver and TypeFounder in the correct 
order, use TypeFounder, then start a ToolDriver script, it fails. I 
found that you have to unload TypeFounder and start it fresh before 
using the ToolDriver. This appears to be due to TypeFounder’s tool 
instances being numbered (i.e. Dictionary6) as they are created. 

This is due to a bug in tool instance numbering. It will be fixed 
in the next release. Thanks for finding it! 

3. Re: The Camera tool image did not print correctly; it appears 

as a broken raster when printed. A similar thing happen when capturing 
screen images in Viewpoint using 'Free Hand Drawing'. This may be 
related to my using a 6085 in both cases. 

Looks like Camera Tool produces garbled images on a 6085 with a 19 
inch display - we found an assumption of 1024 by 808 pixel display 
size in the code. This will be fixed shortly - probably as a 
safe-for-6085’s Typefounder 3.5." 

— Pam 


Date: Thu 3 Jul 86 10:34:19-PDT 

From: Christopher Lane <LANE@SUMEX-AIM.ARPA> 

Subject: TypeFounder Beta-test Report #3 
To: XDESupport.osbunorthOXEROX.COM 

In regard to the 'X Resolution' field of the printer font, leaving 
it set to 300 worked fine. However, I did find the following algorithm 
for setting the 'X Resolution' field in "Appendix E: Obsolete Strikeout 
variation" in a Xerox Office Systems Division memo titled "Print Service 
Fonts": 
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IF (syntheticUnderline THEN 10000 Else 0) 

+ (delta-in-pixels from baseline to bottom of strikeout)*100 
+ (thickness of strikeout in pixels)*10 

If you divide the constants (10000, 100 and 10) by 10 you get an 
algorithm that seems to account for the values in the X Resolution 
field of the current printer fonts. 


Sender: "Jeff rey«-L.^-Roberts.osbunorth"@Xerox .COM 
Date: 7 Jul 86 09:42:18 PDT (Monday) 

Subject: Re: TypeFounder Beta-test Report #3 
From: JLRoberts.osbunorth@Xerox.COM 


Re: Should it come up, who would we contact to be assigned character 
set numbers in the Xerox character code standard? My guess is that 
a small block of numbers would satisfy Stanford's needs for quite a 
while. 

You should contact me with that request. I will act as your agent 
in submitting the request to the Xerox standards board. I assume that 
you want some unique character code assignments. Send me a list of 
the names of characters you would like added, including their graphic 
representations. You can mail it to me at 

Attn: Jeff Roberts 
Mail Stop SVHQ-802 
Xerox Corporation 
475 Oakmead Parkway 
Sunnyvale, CA 94086 

Jeff 


Sender: "Larry<-Rosenberg . osbunorth"@Xerox .COM 
Date: 24 Jul 86 10:51:24 PDT (Thursday) 
Subject: RE: TypeFounder Beta-test Report #4 
From: XDESupport.osbunorth@Xerox.COM 


Here are the developers' answers to your latest beta-test report. 
Larry 


QUESTION 1. Using the same script, files and steps (as far as I can 
tell) that I used to make working printer font dictionaries, some of 
the font dictionaries would cause the printer to crash during font 
cataloging. The backstop log for these crashes all had one of two 
entries: 

July 15, 86 19:07:03 reason: address fault, pc: 25700B 
gf: 143604B, module name: FontDictionaryBImpl 
PSBIndex:0 

July 15, 86 19:12:09 reason: address fault, pc: 637B 
gf: 143604B, module name: FontDictionaryBImpl 
PSBIndex:0 

Given a font dictionary that didn't work, I would go back and change 
the sizes of a few of the fonts in by a mica (or two) and make the 
dictionary again and it would work. Going from a contour master to 
a printer dictionary, it seems that I should be able to specify any 
mica size (to the CONVERTER tool) and the font should be internally 
consistent and not crash the printer. 

ANSWER 1. Any mica size should work, but it is important to remember 
that the print services software converts micas to points using a 
conversion factor of 72 points per inch, whereas Typefounder uses the 
international standard of 72.289 points per inch. We suggest specifying 
the size for the AC files in micas, using values found in the table 
in the "Printing Resolution Sizes" section of Appendix G of the 
Typefounder Reference Manual. 
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We have not experienced address faults cataloging fonts, nor are we 
experts on debugging print services software. If you want to supply 
XDESupport with the contour masters and a script that produces a font 
dictionary that crashes, we will forward them on to the developers 
who would try and reproduce the problem. If you do send anything, 
please make it clear that the developers are aware of this problem 
and have asked to see the scripts and the masters. 

Question 2. It would be useful if the labels in the Typefounder tool 
windows were selectable in some way. After you've 'taught' Typefounder 
and are editing the script you may want to add another command that 
you left out while teaching (or are teaching an old script new tricks). 
Then you could go to, say the CONVERT tool, select the label for "Size 
in micas ' and have the COPY key insert "Size' in' micas' " into your 
script (the auto-quoting would help a lot too) possibly along with 
the tool name and sub-window information at the front. 

ANSWER 2. Thats a nice idea, but XDE provides no way that we know 
of to select a form subwindow label, so I don't believe it is 
implementable. For now, it would probably be easiest to put Typefounder 
into 'teaching ToolDriver mode’ long enough to make a script fragment 
containing the commands you need, and edit them in. 


QUESTION 3. In the last stage of Typefounder starting, it prints 
'Loading Typefounder tools...’ and turns the cursor to an hour glass 
(waiting) cursor which doesn’t seem appropriate as other tools on the 
screen are still active and can still make use of the (normal) cursor. 

ANSWER 3. The hourglass cursor is deliberate, to discourage users 
from trying to create other tool windows while Typefounder is starting 
There is a bug that can (if the timing is just right) cause an address 
fault when new windows receive a mouse action if they were created 
when Typefounder was loading its tools. The bug is still being worked 
on. 


QUESTION 4. It seems that a typical operation you want to do is go 
from a contour master to a printer dictionary of standard sizes (say 
those listed on page 69). It would be nice if there was a tool that 
let you do this directly; the tool would have less flexibility than 

doing each step separately but would simplify this operation. This 

would also be useful when you are only testing out a particular font 
and aren't worried about minor irregularities. Possibly this tool 
could have some speed gains by reusing intermediate computations that 

get thrown away in the current font by font script approach. 

ANSWER 4. Interesting idea, but we will probably not implement this. 

We find in practice that Converter parameters need to be set differently 
for different printing sizes, and that the current script mechanism 
provides this flexibility. 


QUESTION 5. We discovered, by accident, that if your Interpress master 
requests a font that the 8046 printer doesn't have, but it does have 
one (exactly) 1/2 the requested size, it will scale up the smaller 
font to meet the request. I've never seen this documented anywhere; 
what document would describe this and other such 'features' of the 
printer?. 

ANSWER 5. We have also discovered this by accident. The Print Service 
section of the System Administration Library makes no mention of it, 
and we don't know of other documentation. 

QUESTION 6. The documentation for the CONVERTER tools mentions 
'half-bitting' in a couple of places but doesn't mention why you would 
or wouldn’t want to use it (whether it's useful for small or large 
fonts, etc.). 

ANSWER 6. We'll add more information to the manual on when to use 
half-bitting. It’s basic purpose is to provide an appearance compromise 
when ideal stroke widths are close to N.5 bits, where N is some small 
number. It is most often used in making the smaller sizes (6 to 14 
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points) of printer fonts, where it can smooth the progression of 
apparent color as point size changes. Heavy half-bitting is especially 
useful when the ideal cap stroke thickness is greater than the lower 
case stroke thickness. 


QUESTION 7 At the bottom of page 73 in the manual, considering the 
step by step nature of the instructions, it seems there should be a 
step 5. involving using the 'Build Dictionary! 1 command since it 
jumps from entering the name of the font into the tool to writing a 
floppy. 

ANSWER 7. We're trying to obtain a copy of the reference manual that 
went to Beta test users so we can check this reference. 


QUESTION 8 If the last item in the list in the NextltemTool does not 
have an end-of-line character after it, it will not be selected 
correctly. I don’t know if this is something that can be fixed or 
not but there should probably be a warning if it can't (if there isn't 
one already that I've missed). 

ANSWER 8. This is a known bug in the 7 Aug 84 version of NextltemTool. 
We fixed it long ago, but forgot to propagate the new version (2 Aug 
85) to the release directories. You will receive the fix in the next 
release of the Typefounder software. 

QUESTION 9 When we were beta-testing the 1186 (Interlisp Dove) for 
XAIS last fall, they would periodically send out collections of the 
more significant bug/feature reports from the various beta-test sites 
so that we could limit redundancy and know what to keep an eye out 
for. It seems that this would be useful for the Typefounder beta-test, 
unless of course you wish to keep us isolated as part of the 
experiment! 

ANSWER 9. Sounds reasonable; it’s under consideration. 


Sender: "Larry*-Rosenberg .osbunorth"©Xerox .COM 
Date: 24 Jul 86 11:23:22 PDT (Thursday) 
Subject: Re: Typefounder knots problem 
F rom: XDESupport.osbunorth@Xerox.COM 


The developers responded to your problem deleting the wrong knot with: 

The algorithm for determining closest knot runs through a list of all 
knots and picks the first one it finds that is within 6 screen pixels 
of the cursor hotspot. When knots are closely spaced, this may indeed 
not be the closest one to the hotspot. For now, we suggest increasing 
display scale until knot centers are more than 6 screen pixels (1/12 
inch) apart. 

Larry 


Sender: "Hoily<-Wanless . osbunorth"QXerox .COM 
Date: 24 Jul 86 18:18:56 PDT (Thursday) 
Subject: Re: TypeFounder Beta-test Report #5 
From: XDESupport.osbunorth@Xerox.COM 


There is no way to load printer fonts across the net; it must be done 
from floppy. This is because the NS Print Service uses access controls 
which will not allow you to store the font files into the protected 
SystemFiles directory where they must go. However, the Install From 
Floppy command bypasses these access controls. There is a 1983 memo 
that says you can load fonts from the net, but it was a specificaton 
that unfortunately was never implemented. 

I don’t know of any tools to make the Print Service more "open", as 
you put it. The Network Services have traditionally been a rather 
closed environment, and this has caused much frustration for the UG 
sites. Was there any particular function you had in mind (besides 
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being able to load fonts from somewhere other than floppies)? 

I have forwarded your Typefounder questions to the implementors, and 
we should have answers from them shortly. 

--Holly 

Sender: "Hoi ly<-Wanless .osbunorth"©Xerox. COM 
Date: 28 Jul 86 16:14:20 PDT (Monday) 

Subject: Displaying background image knots 
From: XDESupport.osbunorth@Xerox.COM 


From the Typefounder developers: 

Re: When using the Background subtool with the Character subtool 
contour editor, the background image doesn't display it's knots which 
would be useful (as an option). Even more useful would be the ability 
to merge a background contour into the foreground." 

The background image will display its knots if you set background color 
to Black. Ability to merge a background contour into the foreground 
will be available in the next release. 

--Holly 


Sender: "Grant«-Ruiz. osbunorth"@Xerox .COM 
Date: 21 Oct 86 11:38:10 PDT (Tuesday) 
Subject: Re: TypeFounder Beta-test Report #5 
From: XDESupport.osbunorthQXerox.COM 


Many moons ago, you submitted a number of Typefounder questions which 
Holly immediately forwarded to our Typefounder implementors. Apparently 
they lost track of the questions until just recently. Since Holly 
is on vacation this week, I'm forwarding their responses to you. Hope 
you still find this interesting/informative. 

Grant 


Question: The manual doesn't explain about the implications of setting 
the 'Coding' field of the Font tool to the option ASCII (instead of 
the XC1 default). Does the 8046 printer accept such files? What are 
the file naming conventions (the Ascii equivalent of XC1-1-1)? What 
are the mapping differences? When do you use the Ascii coding? Etc. 

Answer: The 'Coding' field of the Font tool affects only a very few 
things in Typefounder: 

-- the substitution character used in writing Font Interchange Standard 
(FIS) format files - if coding is XC1 then it is that specified by 
the Xerox Character Coding Standard (360|312), otherwise 177. 

-- the face code used in writing Prepress format (AC, SD, strike etc.) 
files. This code contains a Xerox/ASCII bit, which is set to Xerox 
if Coding is XC1, else to ASCII. 

-- the searching of Prepress dictionaries for fonts that match a certain 
face (e.g. in the Font Window Extract command). The Xerox/ASCII bit 
is significant in determining if a match exists. 

We are not sure if the 8046 printer would accept a file with the Coding 
set to ASCII, but suggest using a Coding of XC1 for font files that 
are to be used by Xerox devices. 


Question: The ToolDriver appears to be set up to use fixed pitch fonts. 
If you set your default font to the TypeFounderScreenl2.strike font, 
a variable pitch font, then the syntax error messages from the 
ToolDriver are mis-aligned. Typically the ToolDriver prints out the 
erroneous line and a line below it with an up-arrow pointing out the 
location of the syntax error. But with a variable pitch font, they 
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don’t line up correctly. 

I looked through the ToolDriver documentation but I didn't see any 
mention of whether you could set its font independently in the the 
User.cm file. If that is possible, it should probably be mentioned 
in the manual or included in the TypeFounderUser.cm example file. 
Otherwise possible fixes are make ToolDriver know about variable pitch 
fonts or make the TypeFounder screen font fixed pitch. 

Answer: The unsupported tool FontMonster can be used to set the font 
in the ToolDriver window to a fixed pitch font which will make syntax 
error messages more readable. A good one to use is GACHA10.STRIKE 
from the UnsupportedFonts directory. 

Question: Though the Ink and/or Shadow commands of the Variations 
tool work fine on the display, I was unable to get them to work with 
the printer when sending inked/shadowed test characters to the printer 
using the Proofer tool (I didn't actually make a font dictionary for 
the printer to test it). Does this actually work on the 8046 printer? 


Are there any tools that make the Print Service more ’open’, like the 
SystemFolder.bed and Applize.bcd tools do for Viewpoint? It seems 
like a lot of the time we're fighting the printer's 'product hardening*. 

Answer: The Proofer tool works without having to put a font dictionary 
on the printer. We are able to proof inked/shadowed test characters 
without any problem. Is it possible that the Proofer tool you used 
was a child of a different font window than the Variations tool's 
parent? 

We agree that the product hardening of Print Services can make things 
difficult, and know of no tools that make it more open. 




